Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.
Начнем с того, что в целом все осталось как было:
VSAN
STANDARD
VSAN
ADVANCED
VSAN FOR ROBO
(25 VM PACK)
Политики хранилищ Storage Policy Based Management (SPBM)
Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:
Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.
Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.
Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.
А вот как выглядит настройка ROBO-издания Virtual SAN:
Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.
На прошедшей конференции VMworld 2015 компания VMware анонсировала программно-аппаратную архитектуру VMware EVO SDDC, которая пришла на смену архитектуре EVO:RACK, которая, в свою очередь, была продолжателем подхода EVO:RAIL, о котором мы уже писали вот тут. SDDC - это концепция Software-Defined Data Center, то есть программно определяемый датацентр, где все физические ресурсы виртуализованы, абстрагированы от оборудования (то есть администратор оперирует логическими сущностями) и управляются из одной точки с помощью специализированного программного обеспечения.
Эта архитектура позволяет вендорам аппаратного обеспечения и OEM-партнерам VMware поставлять интегрированные законченные решения для создания виртуальной инфраструктуры в виде готовых к эксплуатации стоек с оборудованием и развернутым на нем программным обеспечением. На данный момент договоры уже подписаны с Dell, VCE и Quanta (они начнут поставки в первой половине 2016 года), другие вендоры также вскоре объявят о сотрудничестве с VMware.
Такой подход позволяет создать новую инфраструктуру или включить дополнительные ресурсы в уже существующую буквально за несколько часов. Ключевым компонентом такой инфраструктуры является средство управления EVO SDDC Manager. Инфраструктура под управлением EVO SDDC Manager является гиперконвергентной (hyper-converged infrastructure, HCI), то есть все ресурсы виртуализованы (серверы, хранилища и сети), находятся под управлением единого средства и управляются из одной точки.
С точки зрения аппаратного обеспечения, типовой базовый блок VMware EVO SDDC включает в себя 8 серверов, пару коммутаторов 10 Gbit Ethernet, один коммутатор управления и пару 40 Gbit spine-коммутаторов с 32 портами для связи между стойками. Все это уже полностью собрано, скоммутировано и настроено.
Полностью настроенный блок EVO SDDC из 24 серверов в максимальной конфигурации позволяет запустить в облаке предприятия или сервис-провайдера IaaS более 1000 виртуальных серверов или более 2000 виртуальных ПК:
А где же система хранения? - спросит вы. А ее тут нет, все хранение виртуальных машин осуществляется на базе локальных дисков серверов, объединенных в единое пространство хранения с помощью решения VMware Virtual SAN.
С точки зрения программного обеспечения, EVO SDDC включает в себя следующие компоненты:
VMware vSphere
VMware NSX
VMware Virtual SAN
VMware vRealize Operations
VMware vRealize Log Insight
VMware vRealize Automation (опционально)
VMware Horizon Suite (если стойка используется для виртуальных ПК)
Все эти вещи позволяют не только исполнять виртуальные машины, но и обеспечить отказоустойчивость хранилищ, виртуализацию сетей, а также предоставить средства мониторинга, автоматизации и решения проблем.
Вот так выглядит рабочий процесс путешествия стойки от партнера к клиенту и ее ввод в эксплуатацию:
Более подробно об архитектуре VMware EVO SDDC можно узнать из этого документа.
Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.
Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:
Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.
Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.
К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.
Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:
Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.
Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.
Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.
Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!
Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:
В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).
Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.
Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:
Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:
Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:
Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.
Недавно мы писали том, что компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 версии 2.8. Эта версия прошла инспекционный контроль в ФСТЭК России и доступна для загрузки и покупки. В обновленную версию vGate R2 добавлены новые механизмы защиты и расширенные функции по администрированию системы. Сегодня мы расскажем о том, как в vGate R2 выглядит рабочий процесс для пользователей в защищенной среде.
Интересный пост, касающийся поддержки VMware Tools в смешнном окружении, опубликовали на блогах VMware. Если вы взглянете на папку productLocker в ESXi, то увидите там 2 подпапки /vmtools и /floppies:
Это файлы, относящиеся к пакету VMware Tools, устанавливаемому в гостевые ОС виртуальных машин. Перейдем в папку /vmtools:
Тут находится куча ISO-образов с данными пакета (каждый под нужную гостевую ОС), файл манифеста, описывающий имена, версии и ресурсы файлов пакета, а также сигнатура ISO-шки с тулзами, позволяющая убедиться, что она не была изменена.
В папке floppies находятся виртуальные образы дискет, которые могут понадобиться для специфических гостевых ОС при установке драйверов (например, драйвер устройства Paravirtual SCSI):
Интересно, что папка productLocker занимает примерно 150 МБ, что составляет где-то половину от размера установки VMware ESXi. Именно поэтому рекомендуют использовать образ ESXi без VMware Tools ("no-tools") при использовании механизма Auto Deploy для массового развертывания хост-серверов.
Самая соль в том, что версия пакета VMware Tools на каждом хосте разная и зависит от версии VMware ESXi. Например, мы поставили на хосте VMware vSphere 5.5 виртуальную машину и установили в ней тулзы. Консоль vCenter покажет нам, что установлена последняя версия VMware Tools:
Однако если у нас смешанная инфраструктура (то есть, состоит их хостов разных версий), то при перемещении машины на хост с более высокой версией, например, vSphere 5.5 Update 2/3, она будет показана как ВМ с устаревшей версией пакета (VMware Tools: Running (Out-of-Date):
Поэтому возникает некоторая проблема в смешанной среде, которую можно решить очень просто - как правило VMware Tools от хоста с большей версией подходят ко всем предыдущим. Например, тулзы от vSphere 6.0 подойдут ко всем хостам до ESXi 4.0 включительно. vSphere 6 Update 1 выпадает из списка (постепенно поддержка старых версий уходит):
Таким образом, лучше всего распространить тулзы от vSphere 6 на все хосты вашей виртуальной инфраструктуры. Для этого создадим общий для всех хостов датастор SDT и через PowerCLI проверим, что к нему имеет доступ несколько хостов, командой:
Get-Datastore | where {$_.ExtensionData.summary.MultipleHostAccess -eq “true”}
Далее создадим на этом датасторе папку productLocker:
в которую положим VMware Tools от ESXi 6.0:
Далее нужно пойти в раздел:
Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation
и вбить туда путь к общей папке, в нашем случае такой:
/vmfs/volumes/SDT/productLocker
Если вы хотите применить эту настройку сразу же на всех хостах кластера, то можно использовать следующий командлет PowerCLI:
Теперь для применения настроек есть два пути: первый - это перезапустить хост ESXi, но если вы этого сделать не можете, то есть и второй путь - выполнить несколько команд по SSH.
Зайдем на хост ESXi через PuTTY и перейдем в папку с /productLocker командой cd. Вы увидите путь к локальной папке с тулзами на хосте, так как это ярлык:
Удалим этот ярлык:
rm /productLocker
После чего создадим новый ярлык на общую папку на томе VMFS с тулзами от vSphere 6.0:
Вот таким вот образом можно поддерживать самую последнюю версию VMware Tools в виртуальных машинах, когда в вашей производственной среде используются различные версии VMware ESXi.
Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.
Напомним, как это должно выглядеть (два сайта на разнесенных площадках и witness-хост, который обрабатывает ситуации разделения площадок):
Основная идея такой конфигурации в том, что при отказе отдельного хоста или его компонентов виртуальная машина обязательно должна запуститься на той же площадке, где и была до этого, а в случае отказа всей площадки (аварии) - машины должны быть автоматически запущены на резервном сайте.
Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:
Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.
Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.
Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":
На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:
Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.
На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.
Далее идут настройки Admission Control:
Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.
Далее идет настройка Datastore for Heartbeating:
Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".
Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.
Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.
Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:
vSphere HA
Turn on
Host Monitoring
Enabled
Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss”
Disabled (по умолчанию)
Virtual Machine Monitoring
Опционально, по умолчанию "Disabled"
Admission Control
30-50% для CPU и Memory.
Host Isolation Response
Power off and restart VMs
Datastore Heartbeats
Выбрать "Use datastores only from the specified list", но не выбирать ни одного хранилища из списка
Ну и должны быть добавлены следующие Advanced Settings:
Компания VMware выпустила обновление для прошлой версии платформы виртуализации - vSphere 5.5 Update 3. Не секрет, что большое количество компаний еще использует версию 5.5, так как на больших предприятиях процесс апгрейда ПО и лицензий протекает очень медленно. Поэтому данное обновление им будет весьма кстати.
Что нового в VMware vSphere 5.5 Update 3:
Управление механизмом ротации логов - теперь можно задавать ограничение по размеру лог-файлов в vmx (для каждого лога) и количество хранимых логов.
Сертификация адаптера PVSCSI – теперь устройство виртуальных дисков PVSCSI можно использовать для кластеров MSCS, а также кластеризации приложений, таких как Microsoft SQL или Exchange. Это позволит существенно повысить производительность по сравнению с адаптерами LSI Logic SAS.
Поддержка новых процессоров серверов - теперь платформа поддерживает последние поколения процессоров от Intel и AMD. Подробнее об этом написано в VMware Compatibility Guide.
Аутентификация серверов ESXi в Active Directory – ESXi поддерживает шифрование AES256-CTS/AES128-CTS/RC4-HMAC для коммуникации Kerberos между ESXi и Active Directory.
Поддержка новых баз данных - теперь vCenter Server поддерживает следующие СУБД:
Oracle 12c R1 P2 (12.1.0.2)
Microsoft SQL Server 2012 Service Pack 2
Microsoft SQL Server 2008 R2 Service Pack 3
Поддержка новых операционных систем - новые гостевые ОС теперь полностью поддерживаются:
CentOS 7.0
Oracle Linux 7.0
Ubuntu 14.10
Windows 10
RHEL 6.6
RHEL 7 .1
CentOS 7.1
Oracle Linux 7.1
File Transfer Log – теперь в лог-файлы пишется информация о файлах, переданных на хост ESXi или загруженных с него через vSphere Web Client или vSphere Client.
Также были обновлены несколько сопутствующих продуктов для виртуальной инфраструктуры. Вот ссылки:
Как мы недавно писали, в вышедшем обновлении VMware vSphere 6 Update 1 есть полноценное средство обновления компонентов виртуальной инфраструктуры vSphere Update Manager (VUM), доступное для vSphere Web Client. Ранее VUM можно было использовать только из "толстого" (C#) клиента vSphere Client, и это было одной из ключевых причин неиспользования веб-клинта от VMware в крупных инфраструктурах.
Теперь vSphere Update Manager полноценно присутствует как оснастка Web Client:
Кстати, если вы хотите использовать Update Manager в vCenter Server Appliance (vCSA), то вам все равно придется скачать ISO-шник vCenter для Windows, так как VUM находится именно там.
В левом сайдбаре можно выбрать нужный сервер Update Manager и работать с ним. Пройдитесь по настройкам на вкладках:
Далее нужно создать новый базовый уровень (Baseline) по обновлениям. Нажмите зеленый плюсик в разделе Hosts Baselines:
Также базовый уровень можно создать для виртуальных машин (обновления VMware Tools) и виртуальных модулей (Virtual Appliances):
Создадим новый базовый уровень:
Отмечаем правила для обновления виртуальных модулей:
На вкладке Patch Repository вы видите не только список автоматически добавленных патчей для хостов, но и можете добавить патчи вручную через Web Client:
Для разных хостов можно применять разные образы обновлений VMware ESXi (добавляются вручную) и даже делать это одновременно:
В разделе VA Upgrades можно посмотреть доступные версии виртуальных модулей, а удобная функция по клику на ссылку "EULA" в соответствующей колонке позволяет не принимать условия лицензии каждый раз при развертывании. Нажимаем "Go to compliance page":
Попадаем в раздел vCenter, где мы можем привязывать базовые уровни к хостам, сканировать на наличие обновлений, тестировать обновления путем их "отстаивания" на выделенных для целей стейджинга хост-серверах, а также проводить обновление хостов (Remediate):
В контекстном меню Web Client для хостов есть пункт Update Manager, который позволяет вызвать его функции (например, просканировать на наличие обновлений или обновить):
Более подробно об Update Manager для vSphere Web Client можно прочитать вот тут. Материалы статьи взяты тут.
Таги: VMware, vSphere, Update, Update Manager, ESXi, Web Client
После краткого анонса на прошедшей недавно конференции VMworld 2015, компания VMware объявила о выпуске первого пакета обновления для своей флагманской платформы виртуализации - VMware vSphere 6 Update 1 (включая ESXi 6.0 Update 1 и vCenter 6.0 Update 1).
Что нового появилось в Update 1 (полезного, прямо скажем, немного):
Customer Experience Improvement Program (CEIP) - возможность принять участие в программе улучшения продуктов VMware (без передачи данных о клиенте).
Интерфейс Suite UI теперь включен по умолчанию в vSphere Web Client.
Поддержка SSLv3 теперь отключена по умолчанию.
vCSA Authentication for Active Directory - теперь виртуальный модуль с vCenter поддерживает только методы шифрования AES256-CTS/AES128-CTS/RC4-HMAC для аутентификации Kerberos между vCSA и Active Directory.
Поддержка установщика HTML 5 для нового развертывания и апгрейда:
Установка с установщиком HTML 5 для целевого vCenrer Server - поддерживается.
Апгрейд с установщиком HTML 5 для целевого vCenrer Server - не поддерживается.
Апгрейд vCenter Server из командной строки - поддерживается.
Виртуальный модуль vCSA можно развернуть как напрямую на ESXi, так и через сервер vCenter на хосте ESXI.
Возможность конвертации vCSA во внешний Platform Services Controller (PSC).
Интерфейс VMware Appliance Management Interface (VAMI) в виртуальном модуле vCSA теперь вернулся и доступен по ссылке https://[ip-адрес или имя VCSA]:5480.
Возможность накатывания патчей по URL (по умолчанию указан онлайн-репозиторий VMware).
Отдельный HTML 5 интерфейс для PSC, доступный по ссылке:
https://[IP-адрес VCSA]/psc
Это нужно для того, чтобы администратор мог работать с конфигурациями Single Sign-On (SSO) и другими связанными функциями, когда vSphere Web Client по каким-либо причинам недоступен.
Build-2-Build upgrade support - обновлять виртуальный модуль vCSA можно по новой схеме обновлений: не обязательно ставить новый модуль поверх предыдущей версии. Теперь можно смонтировать новый ISO-образ в уже готовую виртуальную машину с vCSA и запустить процедуру обновления.
Скачать VMware vSphere 6 Update 1 можно по этой ссылке.
Наконец-то стал доступен полноценный Update Manager Web Client. Одна из главных причин, по которым пользователи не отказывались от старого vSphere Client для Windows (так как в нем есть полноценный VUM), теперь устранена.
Также в Update Manager появилось следующее:
libxml обновлен до версии 2.9.2.
Опция реинициализации СУБД для VUM теперь доступна Update Manager Utility в категории Database Settings.
Поддержка новых СУБД.
Microsoft SQL 2008 R2-SP3
Microsoft SQL 2012 SP2 (Standalone и Clustered)
Microsoft SQL 2014(Clustered)
Microsoft XML обновлен на MSXML6.dll.
Oracle (Sun) JRE package обновлен на версию 1.7.0_80.
По умолчанию отключена поддержка SSLv3.
Скачивается VMware vSphere Update Manager 6.0 Update 1 вместе с vCenter.
Сегодня мы расскажем о VMware Cloud Native Applications - стратегии VMware по распространению облачных приложений в контейнерах. Концепция эта основана на двух проектах, которые, возможно, были известны некоторым из вас ранее - Project Bonneville/Pacific и Photon/Lightwave. О проектах Photon и Lightwave мы уже писали вот тут. А вот про Project Bonneville можно почитать здесь.
Напомним, что Photon - это Linux-платформа с минимально необходимым набором средств для запуска контейнеризованных приложений, средств управления средой и взаимодействия с гипервизором VMware vSphere (сейчас минимальная конфигурация этого дела весит около 25 МБ):
Состоит данная среда из двух компонентов: Photon Controller, управляющий развертыванием новых экземпляров виртуальных машин и аутентификацией пользователей (Lightwave), а также Photon Machine - собственно хост, позволяющий запускать экземпляры виртуальных машин с контейнерами приложений (на базе "микровизора" ESX, совместимого по железу с обычным ESXi):
Сама технология использования контейнеризованных приложений называется vSphere Integrated Containers (VIC), она позволяет на базе Photon OS запускать контейнеризованные приложения в среде VMware, включая приложения упакованные средствами Docker.
Photon Controller использует механизм VMFork (сейчас эта технология называется VMware Instant Clone и доступна в vSphere 6) для создания мгновенных экземпляров виртуальных машин (менее 1 секунды) с нужным приложением по запросу от пользователя. Интересно, что в одном экземпляре ВМ работает только один контейнер приложения, что как бы несколько странно для контейнерной виртуализации, но так себе видит эту тему VMware.
Уверяют, что для этой технологии можно будет использовать те же самые серверы, на которых сейчас работает ESXi.
Средство VMware Photon Controller выйдет уже совсем скоро, а вот закрытая бета VMware Photon Platform и Pivotal Cloud Foundry and Photon Platform (интегрированная инфраструктура Photon в PaaS-платформу от VMware) выйдет ближе к концу года:
Более подробно о VMware Cloud-Native Apps рассказано на этой странице. Ну а для тех, кто хочет погрузиться в технические детали, есть вот такая презентация с VMworld 2015:
На прошедшей конференции VMworld 2015 было сделано много интересных анонсов о продуктах и технологиях VMware. Мы уже писали о новой версии VMware Horizon 6.2 (которая, кстати, уже доступна для скачивания), новых возможностях VMware SRM 6.1 и новых функциях VMware Virtual SAN 6.1. В этой же статье мы расскажем о тех нововведениях, которые нас ожидают в ближайшее время в плане облачной инфраструктуры VMware vCloud Air.
Во-первых, VMware представила технологическое превью Project SkyScraper, представляющего собой набор утилит, интерфейсов и функций облачной инфраструктуры vCloud Air для создания унифицированного гибридного облака, объединяющего корпоративную инфраструктуру предприятия и облачную инфраструктуру сервис-провайдера в единое пространство вычислительных ресурсов:
В рамках процесса "гибридизации" облаков будут поддерживаться следующие возможности, функционально доступные из VMware vSphere Web Client:
Cross-Cloud vMotion - это возможность прозрачной для виртуальных машин и пользователей миграции между корпоративной инфраструктурой и облачным датацентром (и обратно) без простоя ВМ. То есть, все как при обычном vMotion. Данную возможность мы уже рассматривали в рамках описания возможностей VMware SRM 6.1. Со стороны сервис-провайдеров также будут внесены изменения в решение vCloud.
Content Sync - возможность синхронизации вспомогательной инфраструктуры для виртуальных машин и данных между частной и облачной инфраструктурой в целях обеспечения возможностей непрерывной отказо- и катастрофоустойчивости на уровне всей инфраструктуры. К синхронизируемым объектам относятся шаблоны виртуальных машин (Templates), виртуальные сервисы (vApp), ISO-файлы и скрипты, которые синхронизируются с их копиями в content catalog на стороне vCloud Air.
Эти две возможности будут доступны посредством VMware vCloud Air Hybrid Cloud Manager, загружаемого как дополнение к vSphere Web Client, и имеющего опциональные функции по управлению платными подписками на IaaS-услуги VMware.
Помимо Project SkyScraper были анонсированы следующие сервисы облака vCloud Air:
VMware vCloud Air Disaster Recovery - это возможность использовать решение SRM как услугу для создания катастрофоустойчивой инфраструктуры между своим датацентром и облаком vCloud Air.
Кстати, вот доступные цены на сервисы DRaaS от VMware (подробнее - тут):
VMware vCloud Air Object Storage - возможность облачного хранения неструктурированных файлов на уровне предприятия. Основано на платформе Google Cloud Platform:
Технический обзор этой возможности:
VMware vCloud Air SQL - это сервисы баз данных как услуги (DBaaS), которые позволяют получать ресурсы СУБД по требованию и масштабировать их по мере возрастания нагрузки. Подробнее об этом рассказано вот тут. Поддерживается Microsoft SQL.
VMware vCloud Air Hybrid Cloud Manager - консоль управления гибридной облачной инфраструктурой, совместимая с vSphere Web Client и имеющая функции управления облачными сервисами и платными услугами облака VMware vCloud.
VMware vCloud Air Advanced Networking Services - это сетевые службы, обеспечивающие перечисленные выше возможности на уровне сетевой инфраструктуры (см. картинку выше). Многие из них доступны только совместно с решением VMware NSX. К таким решениям относятся:
Intelligent Routing - средства умной маршрутизации для собственной и облачной инфраструктуры.
Strong Encryption - сервисы шифрования данных.
WAN Acceleration - сервисы сжатия и оптимизации трафика.
VXLAN extension - инструменты создания прозрачной Layer-2 инфраструктуры между собственными и облачными виртуальными машинами.
Direct connect - выделенный доступ к облачной инфраструктуре по защищенным каналам. Про эту возможность мы писали вот тут.
Сервисы гибридного облака VMware vCloud Air представлены также на вот этой инфографике. Основная страница облачных услуг VMware находится вот тут. На некоторые сервисы уже можно направить запрос на Early Access.
Как вы знаете, на конференции VMware VMworld 2015 было сделано немало интересных анонсов. О некоторых из них мы уже писали - это объявления о выходе VMware Virtual SAN 6.1 и VMware Horizon 6.2. Сегодня мы расскажем еще об одной интересной новости с VMworld - выпуске решения для обеспечения катастрофоустойчивости виртуального датацентра VMware Site Recovery Manager 6.1.
1. Управление защитой данных на базе политик
Напомним, что в VMware vSphere есть понятие Storage Profile - это профиль хранилища, используемый механизмом Profile Driven Storage, который создается, как правило, для различных групп хранилищ (Tier), где эти группы содержат устройства с похожими характеристиками производительности. Виртуальную машину при создании или миграции можно разместить на хранилище, соответствующем требованиям к производительности и надежности:
В SRM 6.1 появился новый тип Protection-групп - storage policy-based protection groups. Они используют механизм vSphere Storage Profiles для идентификации виртуальных машин и добавления их в группы. Также существенно упрощается настройка защищаемых хранилищ.
Теперь профилю хранилищ, а также отдельным хранилищам, можно назначить тэг, которым можно оперировать при создании групп, сортировке или поиске элементов:
Кроме того, появилась интеграция со средствами развертывания виртуальных машин, такими как VMware vRealize Automation.
2. Поддержка растянутых кластеров и vMotion между датацентрами.
Раньше пользователям приходилось выбирать между использованием Site Recovery Manager и vSphere Metro Storage Clusters (так называемые Stretched Clusters, vMSC). Теперь обе этих технологии используются совместно.
Site Recovery Manager 6.1 теперь поддерживает и координирует исполнение операций cross-vCenter vMotion для обеспечения единого пространства отказо- и катастрофоустойчивости для распределенных датацентров:
Таким образом, SRM 6.1 вобрал в себя все преимущества "растянутых" кластеров:
Интеграция растянутых кластеров и VMware SRM 6.1 позволяет реализовать следующие сценарии, ранее доступны только в vMSC:
Плановое обслуживание оборудования целого датацентра - исполнение плана миграции виртуальных машин на другую площадку под управлением другого vCenter прозрачно для пользователей и приложений.
Нулевой простой при сбоях - исполнение плана аварийного восстановления в сочетании с cross-site vMotion (эвакуация машин) поможет избежать простоев при авариях и прочих неприятностях. Ранее такой план мог быть выполнен только путем остановки машин в основном ЦОД и последующим запуском на резервной площадке.
Вот как исполнение плана с подобным сценарием выглядит в консоли SRM:
Также функции растянутого кластера и vMotion между датацентрами будут востребованы при тестировании плана аварийного восстановления в распределенных ЦОД.
3. Улучшенная интеграция с VMware NSX.
Интеграция с решением для виртуализации сетей VMware NSX решает такие проблемы, как разделение сетей в двух датацентрах, необходимость обечить единое пространство миграции vMotion и создание изолированного сетевого окружения для тестирования плана аварийного восстановления.
Используя новые логические коммутаторы NSX, которые охватывают несколько серверов vCenter, Site Recovery Manager позволяет автоматически создать маппинги виртуальных сетевых ресурсов сред при создании плана восстановления, что снижает эксплуатационные расходы и сокращает время, необходимое для настройки.
Объекты Universal Logical Switches объединяют два сетевых домена vCenter на уровне Layer-2, позволяя создавать виртуальные группы портов, которые подключены к виртуальным коммутаторам обеих площадок.
В этом случае Site Recovery Manager автоматически определяет и сопоставляет сети основного и резервного сайтов, никаких ручных операций по настройке маппинга не требуется:
В случае сбоя на основной площадке, необходимые параметры сети и настройки безопасности (включая IP-адреса, security groups, параметры сетевого экрана и конфигурации оконечных устройств) применяются на восстанавливаемых виртуальных машинах, что дополнительно сокращает время восстановления.
Сам NSX 6.2 поддерживает автоматическую синхронизацию сетевых настроек между площадками, поэтому тестирование планов аварийного восстановления может происходить почти в автоматическом режиме, без необходимости ручных операций по приведению сетевых настроек в соответствие друг другу.
Доступность для загрузки VMware Site Recovery Manager 6.1 ожидается в ближайшее время, пока можно следить за новостями на странице обновленного продукта.
На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.
Давайте взглянем на новые возможности этого решения:
1. Virtual SAN Stretched Cluster.
Теперь VSAN будет позволять создавать географически "растянутый" кластер хранилищ между датацентрами, продолжая обеспечивать функции отказоустойчивости. Репликация данных при этом работает с синхронном режиме.
2. Virtual SAN for Remote Office / Branch Office (ROBO)
В VSAN теперь появилась возможность развертывать множество двухузловых кластеров хранилищ, которыми можно централизованно управлять из одной консоли отдельного VMware vCenter Server, предназначенного для этой задачи. Этот сценарий подходит для компаний с большим числом небольших филиалов:
3. Virtual SAN Replication with vSphere Replication
Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.
Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:
4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).
Теперь виртуальные машины, защищенные технологией FT, полностью поддерживаются со стороны VMware Virtual SAN 6.1, то есть кластер непрерывной доступности из виртуальных машин теперь защищен как со стороны вычислительных ресурсов, так и со стороны хранилищ.
5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).
В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:
6. Максимальная производительность и высокая скорость отклика.
Здесь было сделано 2 серьезных улучшения:
Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.
7. Virtual SAN Health Check Plug-in.
Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:
8. Virtual SAN Management Pack for vRealize Operations.
Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:
Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.
В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.
Наверняка некоторые из вас знают, что в новой версии платформы виртуализации VMware vSphere 6 появилась полезная возможность Guest User Mappings. Она позволяет пользователю инфраструктуры SSO (Single-Sign On) предоставить доступ в гостевую ОС виртуальной машины, чтобы постоянно не вводить логин-пароль, а сразу получать доступ к приложениям внутри ВМ. Для этого используется механизм Guest Authentication (vgauth).
Делается это в следующем разделе VMware vSphere Web Client выбранной виртуальной машины:
Manage -> Settings -> Guest User Mappings
Здесь мы нажимаем кнопку "Authenticate" и вводим логин и пароль администратора гостевой ОС:
Далее нажимаем "+" и выбираем пользователя SSO, который будет иметь доступ к консоли виртуальной машины. Его аутентификация будет проходить автоматически:
После этого для данного аккаунта SSO (пользователя vSphere) можно работать с виртуальной машиной и не испытывать неудобств при доступе к ее консоли.
На днях компания Veeam выпустила обновленную версию продукта для комплексного мониторинга и решения проблем в виртуальной среде Veeam Management Pack v8 for System Center.
Новые возможности Veeam Management Pack v8 for System Center:
App-to-metal visibility
Это основная функция решения, которая позволяет организовать отслеживание всех компонентов физической и виртуальной инфраструктуры и связей между ними. Ниже раскрывается сущность этих улучшений, в следующих версиях эти функции будут совершенствоваться.
Полная поддержка VMware vSphere 6 - теперь поддерживаются все новые возможности, такие как Virtual Volumes Datastores (VVOLs), компоненты vCenter, лицензирования и сетевого взаимодействия.
Улучшения Veeam Task Manager for Hyper-V - в новом таск-менеджере поддерживаются виртуальные машины на хранилищах SMB 3.0, а также новые метрики, такие как CPU dispatch time. Кроме того, теперь есть представления кластера Hyper-V и полная совместимость с метриками System Center Virtual Machine Manager и Operations Manager.
Veeam Morning Coffee Dashboard - новое представление с удобной суммарной информацией по инфраструктуре, на которое первым делом смотрит системный администратор за чашкой утреннего кофе. Отчет Morning Coffee содержит такие показатели, как "VM density" (плотность ВМ на хосте) и уровень нагрузки на вычислительные ресурсы и системы хранения.
Capacity planning and right sizing - теперь функции планирования мощностей виртуальной инфраструктуры значительно расширились и теперь содержат следующие сценарии и представления:
- Host Failure Modeling (моделирование ситуации отказа хоста)
- Performance Forecast for vSphere Datastores (прогноз производительности для хранилищ vSphere)
- Performance Forecast for Hyper-V Storage (прогноз производительности для систем хранения Hyper-V)
- Performance Forecast for vSphere and Hyper-V Clusters (прогноз производительности для кластеров vSphere и Hyper-V)
- Virtual Machine Capacity Prediction (прогноз использования ресурсов виртуальными машинами)
- Resize VMs to reclaim resources (перераспределение ресурсов виртуальных машин)
- Capacity planning for hybrid cloud (планирование ресурсов для гибридного облака)
- Capacity planning for Veeam Backup Repositories (планирование ресурсов для репозиториев Veeam Backup & Replication)
Улучшения планирования для Microsoft Azure или VMware vCloud Air
Отчет для планирования ресурсов был обновлен в соответствии с особенностями Azure и vCloud Air, и теперь с его помощью можно точно прогнозировать количество и тип ресурсов для переноса рабочих нагрузок в облако.
Улучшения отслеживания снапшотов
Забытые снапшоты и контрольные точки могут быстро разрастаться, занимать дисковое пространство и снижать производительность системы. С помощью "тепловых карт" (heat maps) вы сможете узнать, для каких виртуальных машин есть снапшоты и контрольные точки. Также доступен подробный отчет по иерархии снимков состояния, с указанием даты создания и комментариев.
Прочие улучшения:
Улучшенная визуализация топологий виртуальных ресурсов
Улучшенная видимость объектов Veeam Backup and Replication
Больше подробностей о Veeam Management Pack v8 for System Center на русском языке можно узнать на этой странице. Скачать продукт можно по этой ссылке.
Таги: Veeam, MP, Update, Microsoft, Hyper-V, System Center, SC VMM, Monitoring
Помните мы как-то писали о проекте VirtualizationMatrix, на котором были представлены сравнения платформ виртуализации? Так вот эти ребята решили замутить еще один проект WhatMatrix, суть которого примерно та же - дать возможность сравнить различные продукты для виртуализации корпоративной инфраструктуры в нескольких аспектах.
Залогинимся и видим, что по дефолту доступно сравнение возможностей VMware vSphere, Citrix XenServer и Red Hat Enterprise Virtualization (мужики какие-то выступают как консультанты в соответствующих категориях).
Почему-то Microsoft Hyper-V не выбран по умолчанию, но его можно выбрать в одной из колонок. Также, помимо платформы виртуализации, выбирается ее издание и версия.
Кстати, обратите внимание, что можно сравнивать продукты разных версий одного вендора между собой, выбрав один и тот же продукт в соседних колонках, что очень удобно:
Можно сколько угодно спорить о предвзятости подобных сравнений, но особая его прелесть в том, что по каждой сравниваемой фиче для каждого продукта можно открыть подробную информацию:
В правой колонке сравнений мы видим "Matrix Score" - это оценка платформы "в попугаях":
А вообще, ребята проделали очень большую и полезную работу - это одно из самых наполненных и актуальных сравнений платформ виртуализации на сегодняшний день. Если с чем-то несогласны - шлите фидбэк, там есть такая кнопка.
Таги: Virtualization, Сравнение, VMware, Microsoft, Citrix, Red Hat, vSphere, Hyper-V, XenServer
Компания VMware на днях выпустила мажнорные обновления своих настольных платформ виртуализации - VMware Fusion 8 и VMware Workstation 12. Помимо полной поддержки Microsoft Windows 10 в качестве хостовой и гостевой ОС, в продуктах традиционно появилось много серьезных нововведений, и их в общем-то можно заслуженно считать лучшими на рынке (хотя стоит взглянуть и на Parallels Desktop 11). Напомним, что про возможности прошлых версий VMware Fusion 7 и VMware Workstation 12 мы уже писали вот тут.
Новые возможности VMware Fusion 8:
Полная поддержка Windows 10 в качестве гостевой ОС:
Поддержка Windows 10 Auto Detect и функций Easy Install
Поддержка Windows 10 для режима Unity
Возможности миграции физической Windows 10 в виртуальную машину
Импорт машины Windows 10 на Boot Camp в ВМ
Поддержка новой версии Mac OS X El Capitan
Возможность запуска Mac OS X El Capitan в виртуальной машине
Поддержка Mac OS X El Capitan в качестве хостовой системы
Поддержка новых гостевых ОС:
Ubuntu 15.04
Fedora 22
CentOS 7.1
RHEL 7.1
Oracle Linux 7.1
VMware Project Photon
Улучшенная поддержка DirectX 10
Улучшенная поддержка OpenGL 3.3
Улучшения производительности при приостановке и включении зашифрованных виртуальных машин
Улучшенные настройки разрешения
Возможность установить глобальные настройки разрешения для ресайзинга окон
Возможность перекрыть эти настройки для отдельной виртуальной машины
Интеграции с VMware vCloud Air (только в версии Fusion 8 Pro)
Возможность просмотреть инвентори виртуальных машин в облаке
Удаленная консоль с мышью и клавиатурой
Возможность загрузки локальной виртуальной машины в облако vCloud Air
Операции с состоянием ВМ (запуск, останов и т.п.)
Улучшенный интерфейс и отзывчивость операций
Улучшенные функции удаленного управления (только в версии Fusion 8 Pro)
Возможность удаленно создать виртуальную машину на платформах VMware vSphere, VMware ESXi и VMware Workstation
Просмотр состояния хостов ESXi на одном дэшборде
Поддержка сети IPv6 NAT (только в версии Fusion 8 Pro)
Поддержка последних макбуков:
Возможность работы с гостевой Windows-машиной на iMac 5K в нативном разрешении
Поддержка нового MacBook
Заглушение эха при голосовых и видеозвонках Microsoft Lync и Skype
Поддержка USB 3.0 для Windows 7 (с последним драйвером Intel)
Улучшенный интерфейс: элементы в меню Пуск и мастер создания виртуальных машин
Добавлено предупреждение для опции "Open your Windows files and web links using Mac Applications", чтобы его замечали пользователи и понимали, что есть такая возможность
Многим из вас знакомо средство vGate R2, которое позволяет защитить виртуальную инфраструктуру предприятия от несанкционированного доступа, а также правильно настроить ее на базе политик. Недавно мы писали о возможностях vGate R2 версии 2.8, а в этой заметке вкратце расскажем о защите данных в государственных информационных системах. Российское законодательство устанавливает ряд обязательных требований по защите информации в среде виртуализации, соблюдение которых регулируется тремя нормативными актами...
Уже где-то год прошел с момента релиза версии 6.1 решения для виртуализации сетей виртуального и физического датацентра VMware NSX. Поэтому VMware давно уже было пора обновить продукт и согласовать его с последними версиями линейки продуктов для серверной и десктопной виртуализации. Как мы все давно ждали, на днях вышла обновленная версия VMware NSX 6.2, где появилась масса нужных новых возможностей.
Приведем здесь основные из них:
1. Поддержка последних версий платформ виртуализации.
VMware NSX 6.2 поддерживает как VMware vSphere 5.5, так и vSphere 6.0. Новые функции в плане сетевого взаимодействия и безопасности между двумя серверами vCenter поддерживаются только для vSphere 6.0.
2. Возможности Cross vCenter Network Virtualization.
В NSX 6.2 поддерживаются окружения, где логические коммутаторы, распределенные логические маршрутизаторы и распределенные сетевые экраны размещены таким образом, что их действие распространяется на объекты с разными vCenter. Официально эта возможность называется Cross-vCenter Network and Security.
Теперь политики фаервола или логических сетевых компонентов могут быть помечены как Universal, что означает, что настройки реплицируются между модулями NSX Manager и будут сохранены при миграции vMotion виртуальной машины на другой хост ESXi, который находится под управлением другого сервера vCenter.
3. Новые универсальные логические объекты сети.
Universal Logical Switch (ULS) - возможность создания логических коммутаторов, которые объединяют несколько серверов vCenter. Это позволяет создать L2-домен сетевого взаимодействия для приложения в виртуальной машине, которое может "путешествовать" между датацентрами.
Universal Distributed Logical Router (UDLR) - это логический распределенный роутер, осуществляющий маршрутизацию между объектами ULS, описанными выше. Этот маршрутизатор работает также и на базе географического размещения ВМ.
Universal IP sets, MAC sets, security groups, services и service groups - все эти объекты поддерживают распределенные структуры с несколькими vCenter.
4. Поддержка VMware vCenter Server 6 с различными топологиями Platform Services Controller (PSC).
Если раньше NSX поддерживала только встроенные сервисы PSC (Platform Services Controller), то теперь поддерживаются различные распределенные топологии (об этом мы писали вот тут). Теперь полностью поддерживаются такие компоненты, как vCenter SSO, license service, lookup service, VMware Certificate Authority и прочее.
5. Поддержка L2 Bridging для Distributed Logical Router.
L2 bridging теперь может принимать участие в распределенной логической маршрутизации. Сеть VXLAN, к которой присоединен экземпляр бриджинга, используется для взаимосоединения Routing instance и Bridge instance.
6. Новый механизм обнаружения IP-адресов для виртуальных машин.
Ранее IP-адреса виртуальных машин обнаруживались по присутствию в них VMware Tools и добавлялись вручную. Теперь есть 2 новых способа добавления адресов: DHCP snooping и ARP snooping (причем присутствие VMware Tools необязательно).
7. Улучшения средств управления и решения проблем.
Тут появились следующие новые фичи:
Central CLI - единый интерфейс командной строки для обычных и распределенных функций NSX.
Traceflow troubleshooting tool - утилита, которая позволяет понять, возникла проблема в виртуальной или физической сети, за счет слежения за прохождением пакета через виртуальный и физический сетевой стек.
Функции Flow monitoring и IPFix теперь можно включать отдельно (раньше можно было только вместе и это создавало много нагрузочного трафика, особенно в больших окружениях).
Отчет в реальном времени о состоянии управляющих компонентов NSX: состояние связей между NSX Manager и агентом сетевого экрана, NSX Manager и консолью управления, между хостами ESXi и NSX Controller.
8. Улучшения LB Health Monitoring.
Теперь доступен гранулярный мониторинг состояния, который предоставляет информацию о произошедших сбоях, а также отслеживает информацию об изменении состояния компонентов NSX и связей между ними. Помимо этого, также предоставляется информация о возможных причинах сбоев.
9. Поддержка диапазона портов для LB.
Теперь для приложений, которым нужно использовать диапазон портов для LB, есть возможность задать этот диапазон.
10. Прочие улучшения.
Возможность сохранять тэг VLAN при коммуникациях VXLAN.
Просмотр активного узла в HA-паре.
Увеличено максимальное число виртуальных IP-адресов.
Поддержка vRealize Orchestrator Plug-in for NSX 1.0.2.
Возможность включения/отключения uRPF check для отдельного интерфейса.
Улучшения Load balancer health monitoring.
Прочие улучшения, полный список которых приведен вот тут.
Скачать VMware NSX 6.2 можно по этой ссылке. Документация по продукту доступна вот тут.
Кроме того, VMware NSX версии 6.2 поддерживает инфраструктуру виртуальных ПК VMware Horizon View версии 6.0.1 и боее поздних (другие продукты вы тоже можете добавить в VMware Product Interoperability Matrix):
Про поддержку VMware Horizon View есть также небольшое видео:
Как вы знаете, с 30 августа по 3 сентября в Сан-Франциско пройдет самая большая и полезная конференция по виртуализации VMware VMworld 2015. Компания StarWind Software, как производитель решения номер 1 для создания программных отказоустойчивых хранилищ Virtual SAN под виртуальные машины, среди прочих примет в ней участие.
Приходите на стенд StarWind под номером #442, чтобы узнать о комплексном решении StarWind Hyper-Converged Platform, включающем в себя следующие компоненты для построения инфраструктуры небольшого предприятия или филиала:
Серверы Dell
Гипервизор VMware vSphere
Решение для резервного копирования и репликации Veeam Backup & Replication
Решение для построения отказоустойчивого программного кластера хранилищ StarWind Virtual SAN
Ну и наиболее активный и сообразительный из вас получит PlayStation 4!
Приходите на стенд StarWind, обещаем много интересного!
На днях компания Microsoft объявила о бесплатной доступности виртуальных машин с новой версией гостевой ОС Windows 10 в виде готовых виртуальных модулей (Virtual Appliances) для самых популярных платформ виртуализации: VMware vSphere / Workstation, Microsoft Hyper-V, Oracle VirtualBox и Parallels Desktop. На хостовой ОС Windows можно использовать платформы Workstation, Hyper-V или VirtualBox, для Mac OS можно использовать VMware Fusion, Parallels Desktop или VirtualBox, а на Linux можно запустить машину только на VirtualBox.
В ближайшее время появятся также машины в других форматах (например, QEMU), так как Microsoft автоматизировала процесс создания этих виртуальных модулей. Сделано все это для того, чтобы пользователи как можно быстрее втягивались в использование браузера Microsoft Edge и новой Windows 10. Кстати, он называется IE11, когда машинку добавляешь в консоль:
Виртуальные машины распространяются как zip-архив размером около 5 Гбайт, где находятся соответствующие файлы ВМ в форматах виртуальных модулей (для VMware это OVA). Сама машина настроена на устаревание через 90 дней после первого включения, соответственно рассматривать ее нужно только как среду для тестирования, а не как производственную машину (так как после устаревания данные будут недоступны). Microsoft рекомендует сразу после загрузки создать снапшот ВМ, чтобы всегда можно было откатиться на чистую систему.
Microsoft также сообщает, что данные виртуальные машины вышли с багом: в настройках иногда появляется сообщение "Connect to the Internet to activate", которое нужно проигнорировать - на функциональность оно не влияет.
Скачать готовые виртуальные машины с Windows 10 можно по этой ссылке.
Таги: Microsoft, Windows 10, Update, Virtual Appliance, VMachines
Интересную утилиту, которая будет полезна всем администраторам Citrix XenDesktop, анонсировал Andrew Morgan. Citrix Director Notification Service - это сервис, который следит за состоянием компонентов инфраструктуры XenDesktop и оповещает администраторов по почте, когда что-то сломалось.
У компании Citrix есть специальный продукт для этих целей - Citrix Director, но он показывает состояние компонентов XenDesktop только в консоли, которую нужно постоянно запускать и обновлять. А Director Notification Service позволит вам это делать автоматически и в реальном времени.
Утилита проверяет состояние следующих компонентов инфраструктуры виртуальных ПК:
Citrix Licensing
Соединение к базе данных
Службу Broker Service
Основные службы XenDesktop (Core Services)
Соединение с гипервизором (это может быть как XenServer, так и VMware vSphere)
Вот так это выглядит:
В случае появления неисправности в XenDesktop, Citrix Director Notification Service посылает письмо администратору с подробным описанием типа неисправности. Когда работа компонента восстанавливается, также посылается письмо.
Интересно, что через Director Notification Service можно ловить алерты от гипервизора. Вот, например, такое ловится от VMware vSphere (у хоста осталось мало памяти):
После установки утилиты нужно запустить Configuration Utility:
Там настраиваются параметры SMTP-сервера для отправки писем, а также параметры доступа к Citrix Desktop Delivery Controller (DDC). Кроме того, доступны настройки и самого сервиса (например, частота опроса компонентов):
Не забывайте нажать кнопки "Test", чтобы проверить настройки.
Ну и после развертывания утилиты надо запустить Director Notification Service. Его можно установить на Edge-компьютер в периметре датацентра, а можно прямо на DDC.
Эта версия утилиты была протестирована на Citrix XenDesktop 7.6, но должна работать и на более ранних версиях платформы.
Прочитать инструкции по установке продукта можно вот тут, а скачать Citrix Director Notification Service можно по этой ссылке.
Эта штука представляет собой сервер и клиент в виде standalone-приложений для доступа к консоли виртуальных машин в продуктах VMware vSphere и VMware Workstation. Имплементация VNC-протокола уже есть в этих продуктах, за счет нее и работает так называемая MKS-консоль в толстом и тонком клиентах vSphere.
VNC-протокол передает сессию на VNC-клиент к удаленному десктопу, на котором установлен VNC-сервер. Утилита работает из командной строки и не имеет UI, но работает аналогично подобным VNC-пакетам:
Надо отметить, что соединения по протоколу VNC не являются защищенными, поэтому рекомендуется их использовать в VPN-сети или в туннеле SSH.
Возможности VNC-клиента и сервера:
Оптимизированы для каналов с ограниченной пропускной способностью
На клиенте консоль сделана в стиле клиентов VMware
Пользователям доступны дополнительные расширения при соединении с виртуальной машиной VMware напрямую или с VMware VNC Server
VNC Server может быть развернут на Windows, Linux или Mac OS X.
VNC Client работает из под Windows и Linux. Скачать VNC Server and VNC Client можно по этой ссылке.
Некоторое время назад мы публиковали несколько заметок о поддержке платформой VMware vSphere открытой архитектуры OpenStack (тут и тут). Ну а недавно VMware собрала все свои видео о поддержке OpenStack в единый плейлист, чтобы удобно было получить информацию о различных аспектах использования этой архитектуры:
С помощью VMware Integrated OpenStack вы можете имплементировать поддержку OpenStack в существующей инсталляции VMware vSphere. Делает это путем развертывания виртуального модуля Integrated OpenStack Manager vApp в VMware vCenter. Затем вы указываете кластер управления и вычсилительные кластеры, пулы хранилищ, настраиваете сетевое взаимодействие и добавляете необходимые ресурсы в консоль управления.
Из этих видео вы узнаете как:
Проводить анализ логов
Выполнять окрестрацию операций
Проводить управление емкостями ресурсов и анализ затрат
Обслуживать и администрировать ресурсы
Обновлять программные компоненты
Осуществлять мониторинг ресурсов и решение проблем
Добавлять проекты (Projects) и пользователей
Управлять группами безопасности
Добавлять образы новых систем
Добавлять хранилища
Добавлять сети
Добавлять инстансы
Непосредственно развертывать инфраструктуру OpenStack
Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.
Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.
В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:
Это, конечно, покатит только если у вас на всех хостах ESXi везде одинаковый пароль root. Но если они там разные, то нужно будет для каждого сервера исполнить соответствующую команду.
Далее просто ищем нужную виртуальную машину по ее имени:
(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost
В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.
Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):
Причина этого - как правило, аппаратные проблемы сервера (барахлящее оборудование, битые блоки памяти, проблемы с драйверами, в том числе виртуальных устройств, и т.п.). В этом случае полезно погуглить ошибку, но сначала нужно получить дамп ядра (core dump), где сохраняются подробности о причине PSOD.
В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":
Далее выбираем интересующий нас хост VMware ESXi:
Затем отчекиваем все галки, кроме CrashDumps:
После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":
Ниже вы увидите подробности о произошедшей ошибке:
В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.
У многих администраторов VMware vSphere зачастую возникает необходимость понизить версию виртуального аппаратного обеспечения (hardware version) виртуальной машины. Это может понадобиться в следующих случаях (и не только):
когда толстый клиент vSphere Client не поддерживает всех функций новой версии Virtual Hardware
новая версия железа не поддерживается старыми хостами VMware ESXi, которые вы еще не успели обновить
если вы пользуетесь услугами внешнего провайдера IaaS (аренда виртуальных машин), то у провайдера может оказаться не самая последняя версия платформы, и при миграции в его облако обновленное Virtual Hardware не будет поддерживаться
Так или иначе, сделать даунгрейд виртуального железа можно, и это достаточно просто. Если апгрейд делается из контекстного меню виртуальной машины в vSphere Client:
То даунгрейд можно сделать одним из трех способов:
Перед апгрейдом виртуального обеспечения нужно сделать снапшот виртуальной машины. При откате к нему произойдет и откат к предыдущей версии виртуального железа.
Можно использовать VMware Converter Standalone для V2V-миграции, при которой можно выбрать нужную версию Virtual Hardware.
Можно создать новую виртуальную машину с нужной версией железа (например, на старом хосте ESXi), к которой прицепить диск от исходной ВМ.
Многие из вас знают о решении StarWind Virtual SAN, предназначенном для создания отказоустойчивых хранилищ. Но не все в курсе, что у StarWind есть виртуальный модуль Virtual SAN OVF (ссылка на его загрузку высылается по почте), который представляет собой шаблон виртуальной машины в формате OVF готовый к развертыванию на платформе VMware vSphere.
Недавно компания StarWind выпустила документ Virtual SAN OVF Deployment Guide, в котором описана процедура развертывания данного виртуального модуля.
Поскольку Microsoft на уровне лицензии запрещает распространение таких виртуальных модулей с гостевой ОС Windows в формате виртуальных дисков VMDK, придется сделать несколько дополнительных операций по развертыванию, а именно:
1. Запустить StarWind V2V Converter.
2. Преобразовать VHDX-диски в формат VMDK.
3. Поместить VMDK и OVF в одну папку.
4. Развернуть OVF на сервере VMware ESXi.
5. Заполнить поля IP-адреса для включения машины в виртуальную сеть.
6. Подождать окончания процесса создания и конфигурации виртуальной машины.
Больше подробностей о виртуальном модуле StarWind Virtual SAN OVF вы найдете в документе.
Таги: StarWind, Whitepaper, Virtual Appliance, OVF, Storage, HA
Компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 (версия 2.8). Эта версия прошла инспекционный контроль в ФСТЭК России (с подтверждением выданных ранее сертификатов соответствия от 28.03.2011 № 2308 и от 12.07.2011 № 2383) и доступна для загрузки и покупки. Таги: vGate, Update, Security, VMware, vSphere, Microsoft, Hyper-V, Security Code
Не так давно компания VMware выпустила интересный документ "VMware Virtual SAN 6.0 Proof of Concept Guide", который позволяет представить себе в голове план пошаговой имплементации решения VSAN во всех его аспектах (хосты ESXi, настройка сети, тестирование решения, производительность, средства управления и т.п.).
Процесс, описанный в документе, представляет собой развертывание кластера Virtual SAN в изолированной среде для целей тестирования, чтобы обкатать решение в небольшой инфраструктуре и потом уже отправить его в производственную среду.
Основные разделы документа освещают следующие темы:
Подготовительные работы
Настройка сетевого взаимодействия
Включение функций кластера хранилищ
Функциональность платформы VMware vSphere при операциях в кластере VSAN
Симуляция аппаратных отказов и тестирование поведения кластера
Управление кластером Virtual SAN
Сам документ содержит 170 страниц и представляет собой ну очень детальное руководство по развертыванию кластера Virtual SAN и его тестированию. Причитав его, вы поймете множество интересных технических особенностей, касающихся принципов работы решения.
Скачать "VMware Virtual SAN 6.0 Proof of Concept Guide" можно по этой ссылке.
RSS
